collection

1.4.1. Vendor 3

Overall we were pleased with the amount of testing and with the results of the testing. Vendor 2 and Vendor 6 testing had never been done previously and was more successful than would have expected. While there was only small progress made since the last test event between Vendor 3 and Vendor 1 and Vendor 7, we certainly pinned down some specific problems that we can address in coming releases which made this event very valuable.

Notes on specific vendors:

Vendor 3:

  • Cancellations to some clients are not honored — likely due to no ATTENDEE listed on cancellation. Notes to investigate and address.

  • Investigate being lenient of missing STATUS:CANCELLED on cancellations coming to us.

  • We will make an attempt to improve user experience around receiving series updates/reschedules.

  • We will consider sending out an alternative block even when sending simplified MIME to provide richer experience for some clients.

  • Overaggressive name matching caused some response tracking errors

Vendor 7a:

  • No major surprises.

  • We do not implement RDATEs on invites/updates/reschedules. Now (incorrectly) says ‘not a valid iCal file’.

  • Does not handle rich content in description.

  • There was a bug found with counter-proposals of a single instance of a repeat set.

  • Comments ARE shown when they come from iCalendar — This has improved since October.

  • Cancel all somewhat worked accidentally via corruption. This is certainly livable but not ideal.

  • There seems to be a display issue with original time on counter-proposals

  • Name matching problems cause response tracking errors

Vendor 7b:

  • Vendor 3 worked largely to the expected extent…​ no major surprises.

  • Does not implement RDATEs on invites/updates/reschedules. They now (incorrectly) say ‘not a valid iCal file’.

  • Does not handle rich content in description.

  • Cancellations do not work. Both Vendor 1 and Vendor 7 have plans to address.

  • Counters are not handled correctly by Vendor 3. Investigation needed.

  • Acceptance notice didn’t seem to come

  • Decline of a counter-proposal from Vendor 3 was not handled.

  • Name matching problems cause response tracking errors

  • Cosmetic issues:

    • Does not append ‘rescheduled’ to a rescheduled meeting.

    • There is timezone munge in the body showing incorrect timezone, but it comes through fine otherwise.

Vendor 6:

  • This testing was very successful even for complicated issues. Good job!

  • Reschedules of a single instance need to increment sequence number. Vendor 6 to address.

  • Questions on why some meetings show plain text and some show rich content — Vendor 6 to investigate

  • Responses from Vendor 3 do not show any body — they will address by including an alternative block even when simplifying MIME.

  • Does not implement counter-proposals

Vendor 1:

  • Still sends ics attachments rather than actual workflow. Some clients (Vendor 4) have hacks to treat this like workflow, but it is not valid. MIME edits to make these ics attachments is minimal, and Vendor 1 is taking these changes back to see if they can implement, although this might be difficult due to limited Mail APIs.

  • Rich text is not handled by Vendor 1 Mail

  • Vendor 1 mail loses attachments from Vendor 3

  • Vendor 3 does not handle Vendor 1’s inline or URI attachments — Vendor 1 to investigate

  • Cancellations from Vendor 1 do not show as such in Vendor 3 (STATUS:CANCELLED problem). Actions by Vendor 3 and Vendor 1 planned.

  • Cancellations from Vendor 3 do not show as such in Vendor 1. This is likely a bug with ATTENDEE not specified.

  • Vendor 1 was not tested very much beyond this as working with the attachments is difficult.

Vendor 1 CalDAV:

  • This is only one way as one cannot invite an Vendor 1 CalDAV user to a meeting (this uses iCal)

  • Cancellations from Vendor 1 do not show as such in Notes (STATUS:CANCELLED problem). Actions by Vendor 3 and Vendor 1 planned.

  • Attachments from Vendor 1 are not working with Vendor 3 — Vendor 1 to investigate.

  • Vendor 3 and Vendor 1 will meet in a month or so to retest some scenarios as server problems stopped testing prematurely and because we have some bugs to fix.

Vendor 2:

  • Vendor 2 testing worked fairly well, with most problems encountered inherited from Outlook.

  • Vendor 2 does not implement RDATEs on invites/updates/reschedules and this causes major data loss.

  • Vendor 2 does not handle rich content in description.

  • Cancellations from Vendor 2 do not show as such in Vendor 3 (STATUS:CANCELLED problem). Actions by Vendor 3 and Vendor 2 planned.

  • Cancellations from Vendor 3 do not show as such in Vendor 2. This is likely a bug with ATTENDEE not specified.

  • Seem to have a problem with Vendor 2 attachments — Vendor 3 to investigate.

  • Counters are not implemented.

  • Updates/Reschedules from Vendor 2 fail. I don’t have the details of this written down but I believe that this was a problem where Vendor 2 did not update the sequence number.